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1^ (54) Title: RANDOM IDENTITY MANAGEMENT IN SCATTERNETS 

(57) Abstract: In an ad-hoc network, netwoik identities are assigned to each network. Using the network identities, a node can 
determine whether a neighbor node (not connected to the node) is a member of the same network as the node or whether a neighbor 
node (not connected to the node) is a member of the same network as another neighbor node (not connected to the node). When two 
networks merge the network identity of one of them is selected and broadcast throughout the part of the merged network that has 
to change its network identity. To avoid multiple networks which were once members of the same network, from having the same 
netwoik identity, network identities are periodically reassigned and broadcast throughout each netwoik. Further, when a connection 
between two nodes is broken the nodes can determine whether they are still members of the same network before initiating a change 
of network identity procedure. 
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RANDOM roENTTTY MANAGEMENT IN SCATTEEtNETS 



BACKGROUND 

The present invention relates to ad-hoc networks- More particularly, the present 
invention relates to forming ad-hoc networks. 

Conventional networking protocols are based on the characteristics and/or features of 
fixed networks. In fixed networks, the network coxrfiguration typically does not change. 
Although nodes can be added and removed m fixed networks, the route traveled by data 
packets between two nodes typically does not change. The disadvantage is that fixed networks 
cannot be easily reconfigured to account for increases m data traffic, also called system 
loading. Accordingly, when system loading increases for one node, the surroxmding nodes are 
likely to experience increased delays in the transmission and reception of data. 

In contrast to fixed networks, ad-hoc networks are dynamic. An ad-hoc network is 
formed when a number of nodes decide to join together to form a network. Since nodes in ad- 
hoc networks operate as both hosts and routers, ad-hoc networks do not require the 
infrastructure required by fixed networks. Accordingly, ad-hoc networking protocols are 
based upon the assun[q)tion that nodes may not always be located at the same physical location. 

Bluetooth is an exemplary ad-hoc networking technology. Bluetooth is an open 
specification for wireless communication of both voice and data. It is based on a short-range, 
universal radio link, and it provides a mechanism to form small ad-hoc groupings of connected 
devices, without a fixed network infrastructure, including such devices as printers, PDAs, 
desktop computers, FAX machines, keyboards, joysticks, telephones or virtually any digital 
device. Bluetooth operates in the unlicenced 2.4 GHz Industrial-Scientific-Medical (ISM) 
band. 

FIG. 1 illustrates a Bluetooth piconet. A piconet is a collection of digital devices, such 
as any of those mentioned above, connected using Bluetooth technology in an ad-hoc fashion. 
A piconet is initially formed with two connected devices, herein referred to as Bluetooth 
devices. A piconet can include up to eight Bluetooth devices. In each piconet, for example 
piconet 100, there exists one master Bluetooth unit and one or more slave Bluetooth units. In 
FIG. 1 Bluetooth unit 101 is a master xmit and unit 102 is a Bluetooth slave unit. 

According to Bluetooth technology a slave unit can only communicate directly with a 
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master unit. FIG. 2 illustrates a piconet with a master unit 201 and a plurality of slave units 
202-208 arranged in a star network topology. If slave unit 202 wishes to communicate with 
slave imit 206, slave unit 202 would have to transmit the information it wished to communicate 
to master unit 201 . Master unit 201 would then transmit the information to slave unit 206. 

A scattemet is formed by multiple independent and imsynchronized piconets. FIG. 3 
illustrates an exen^lary scattemet 300. In FIG. 3, piconet 1 includes a master node 303 and 
the slave nodes 301 » 302 and 304; piconet 2 includes a master node 305 and fixe slave nodes 
304, 306, 307 and 308; and piconet 3 includes a master node 309 and the slave nodes 308, 310 
ajod 311 . To implement a scattemet it is necessary to use nodes which are members of more 
than one piconet. Such nodes are herein referred to as forwarding nodes. If, for example, 
node 301 wishes to communicate with node 310, then nodes 304 and 308 might act as 
forwarding nodes by forwarding information between the two piconets and in particular 
between nodes 301 and 310. For example, node 301 transfers the information to the master 
node of piconet 1 node 303. Master node 303 transmits the information to forwarding node 
304. Forwarding node 304 then forwards the information to master node 305, which in turn, 
transmits the information to forwarding node 308. Forwarding node 308 forwards the 
information to master node 309 which transmits the information to the destination node 3 10. 
Furthermore, it should be pointed out that a single piconet is just a trivial case of the more 
general scattemet concept. Hence, in this document the term ""scattemet" refers to either a 
single piconet or multiple interconnected piconets. 

Each Bluetooth unit has a globally unique 48 bit IEEE 802 address. This address, 
called the Bluetooth Device Address (BD_ADDR) is assigned when fhe Bluetooth unit is 
manufactured and it has never changed. In addition, the Master of a piconet assigns a local 
active member address (AM_ADDR) to each active member of the piconet. The AM_ADDR, 
which is only three bits long, is dynamically assigned and deassigned and is unique only within 
a single piconet. The master uses the AM ADDR when polling a slave in a piconet. 
However, when the slave, triggered by a packet from the master addressed with the slave's 
AM ADDR, transmits a packet to the master, the slave includes its own AM_ADDR (not the 
masters) in the packet header. 

Even though all data is transmitted in packets, the packets can carry both synchronous 
data, on Synchronous Connection Oriented (SCO) links which is mainly intended for voice 
traffic, and as3aichronous data, on asynchronous connectionless links (ACL) links. Depending 
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on the type of packet that is used, an acknowledgment and retransmission scheme is used (not 
for SCO packets transferring synchronous data) to ensure reliable data transfer, as well as 
forward error correction (FEC) in the form of channel coding. 

FIG. 4 illustrates a conventional Bluetooth packet. The conventional Bluetooth packet 
consists of access code 410, header 420 and payload 430. The header 420 contains the 
AM_ADDR followed by some control parameters, e.g., a bit indicating acknowledgment or 
retransmission request of the previous packet, when applicable, and a header error check 
(HEC). The access code 410 in the packet can be of three different types including a channel 
access code (CAC), a device access code (DAQ or an inquiry access code (lAC). 

The channel access code identifies a channel that is used in a particular piconet, i.e., in 
essence fihie channel access code identifies the piconet. Accordingly, all packets exchanged 
within a piconet carry the same channel access code. The channel access code is derived from 
the BD_ADDR of the master unit of the piconet. The device access code is derived from a 
BD ADDR of a particular Bluetooth unit. The device access code is used for special signaling 
procedures, e.g., the PAGE procedure. There are two types of inquiry access codes, the 
general mquiry access code (GIAG) and the dedicated inquiry access code (DIAC). Both the 
general inquiry access code and the dedicated inquiry access code are used in the INQUIRY 
procedure. 

The format of payload 430 depends on the type of packet. The payload of an ACL 
packet consists of a header, a data field and a cyclic redundancy check (CRC). However, 
AUXl packets do not include a CRC and the payload of an SCO packet consists only of a data 
field. In addition, there are hybrid packets including two data fields, one for synchronous data 
and one for asynchronous data. Packets in which the payload does not include a CRC are 
neither acknowledged nor retransmitted. 

Since ad-hoc networks are dynamic, ad-hoc networking technology typically has a 
neighbor discovery feature. The neighbor discovery feature allows one node to find any other 
node with which the first node can communicate, and consequently form an ad-hoc network 
with. A neighbor discovery procedure in Bluetooth is known as the INQUIRY procedure. 
Once a Bluetooth unit knows of neighboring nodes, a Bluetooth unit can coimect to the 
neighboring node using the PAGE procedure. 

FIG. S illustrates the signaling performed between two Bluetooth units for neighbor 
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discovery and connection establishment. A Bluetooth unit, such as Bluetooth unit 1, wishing 
to discover neighboring nodes broadcasts an INQUIRY message. The Bluetooth unit then 
waits and listens for an INQUIRY RESPONSE message. An INQUIRY message consists of 
only an inquiry access code. The inquiry access code can be a general inquiry access code, 
which is sent to discover any Bluetooth unit in the neighborhood, or a dedicated inquiry access 
code, which is sent to discover only certain types of Bluetooth units, for which the particular 
dedicated inquiry access code is dedicated. 

When a neighboring node, such as Bluetooth unit 2, receives an INQUIRY message, 
the neighboring node will respond with an INQUIRY RESPONSE message. The INQUIRY 
RESPONSE message is really an FHS (Frequency Hop Synchronization) packet. A FHS 
packet is illustrated in FIG. 6. The FHS packet includes fields for parity bits, lower address 
part (LAP), Scan Repetition (3R), Scan Period (SP), upper address part (UAP), non-significant 
address part (NAP), class of device, AM_ADDR, internal value of the units clock (CLK), and 
Page Scan Mode, The LAP, UAP and NAP together comprise the BD_ADDR. The SR, SP 
and Page Scan Mode fields are control parameters used during the page procedure. The 
AM ADDR field can be used to assign an AM ADDR to a Bluetooth unit which is becoming 
a slave in a piconet, i.e. , the AM_ADDR field is used only when the FHS packet is used in the 
PAGE procedure, and the undefined field is reserved for fiiture use. 

An FHS packet is also used for other purposes in a Bluetooth system, e.g. , for 
synchronization of the firequency hop channel sequence. By listening for INQUIRY 
RESPONSE messages the Bluetooth unit that initiated flie INQUIRY procedure, e.g., 
Bluetooth unit 1, can collect the BD_ADDR and intemal clock values, both of which are 
included in the FHS packet, of the neigihboring Bluetooth units. 

When a Bluetooth unit desures to establish a connection with a neighboring node the 
Bluetooth unit sends a PAGE message. A PAGE message consists of the Device Access Code 
(DAC) which is derived from the BD_ADDR of the paged Bluetooth unit. A Bluetooth unit, 
e.g., Bluetooth unit 2, receiving a PAGE message including its own DAC responds with an 
identical packet, i.e., a packet including only the DAC of the paged Bluetooth unit. The 
paging Bluetooth unit, i.e., Bluetooth unit 1, then repUes with an FHS packet, including the 
BD_ADDR of the paging Bluetooth unit (Bluetooth unit 1), the current value of the intemal 
clock of the pagmg Bluetooth unit (Bluetooth imit I), the AM_ADDR assigned to the paged 
Bluetooth unit (Bluetooth unit 2) and other parameters. The paged Bluetooth unit (Bluetooth 
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unit 2) then responds with its DAC and thereby the connection between the two Bluetooth units 
is established. 

If the paging Bluetooth unit is already the master of a piconet, the paged Bluetooth unit 
has now joined this piconet as a new slave unit. Otherwise, the two Bluetooth units have just 
formed a new piconet with the paging Bluetooth unit as the master unit. Since the INQUIRY 
message does not include any information about its sender, in particular not its BD_ADDR, 
the Bluetooth unit that initiated the INQUIRY procedure is the only one that can initiate a 
subsequent PAGE procedure. Thus, the Bluetooth unit initiating an INQUIRY procedure will 
also be the master of any piconet that is formed as a result of a subsequent PAGE procedure. 
However, if considered necessary, the roles of master and slave can be switched using a 
master-slave-switch mechanism. This, however, can be a complex and extensive procedure, 
potentially resulting in a redefinition of the entire piconet, involving all other slave units in the 
piconet. 

The INQUIRY and PAGE procedures are well defibaed in the current Bluetooth 
standard. These are all the tools that are needed to form a new Bluetooth piconet or join an 
existing one. However, even though the tools are weU specified, there are no rules or 
guidelines as to how to use them. When neighbors are discovered there is no way to know 
who to connect to in order to form an appropriate piconet. Further, using a master-slave- 
switch mechanism is an extensive procedure and it is difficult to determine when to use it in 
order to improve the ejfficiency of a piconet. Hence, piconets will more or less form at 
random, often resulting in far from optimal piconet and scattemet structures. Further, the 
Bluetooth units forming a piconet or a scattemet will not have an idea as to the structure and 
interconnection of various piconets. 

Piconet and scattemet forming procedures would be facilitated, and more efficient 
piconet and scattemet topologies would be possible to achieve, if more information about the 
involved Bluetooth imits could be exchanged before the piconets and scattemets are actually 
established. Accordingly, it would be desirable to provide pieces of information during the 
INQUIRY and PAGE procedures which aid a Bluetooth unit in determining an efficient 
method for scattemet forming. 

Further, the INQUIRY RESPONSE messages only mclude information about the 
responding node itself. Accordingly, even if an inquiring node would coUect INQUIRY 
RESPONSE messages from all the nodes in its viciniQ^, it would not obtain any information 
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about how these nodes are interconnected, which nodes would be reachable through each 
other, and which nodes are connected to the same scattemet. Having a picture of how the 
different neighboring nodes are interconnected via "islands of connectivity" in the form of 
separate scattemets, would be valuable information for a node trying to establish connectivity, 
especially while trying to establish a so-called Maximum Connectivity Scatternet (MCS). For 
more information regarding Maximum Connectivity Scattemets the interested reader should 
refer to U.S. Provisional Application No. 60/210,908, which is herein expressly incorporated 
in its entirety by reference. 

Since no information regarding what nodes belong to the same scattemet is included in 
the INQUIRY RESPONSE message, i.e., in an FHS packet, the inqmring node must first 
establish a connection to the responding node before it can, potentially, find out what other 
nodes that are reachable through it. Further, even then there is no simple mechanism to collect 
this infonnation. In addition, establishing connections in order to gather information is a time 
consuming and resource demanding procedure, which could be greatly simplified if more 
information could be transferred in the INQUIRY RESPONSE message. 

SUMMARY 

These and other problems, drawbacks and limitations of conventional techniques are 
overcome according to tibie present invention by assigning network identities to each network. 
During paging procedures nodes can determine whether the responding nodes are members of 
the same network by comparing network identities. 

The present invention provides various apparatus and methods for initial selection of 
the network identity. In addition, when two networks merge, the present invention provides 
methods and apparatus for selecting which network identity should be used by the new merged 
network. Further, to prevent two networks which were once part of the same network from 
having the same network identity, the present invention provides for periodically changing the 
network identity. In addition, the present invention allows nodes which have broken a 
connection between them to determine whether they are still members of the same network 
before broadcasting a message to change the network identity. 

By providing a network identity, nodes in ad-hoc networks can determine how neighbor 
nodes are interconnected. Further, a node can determine whether a neighbor node is already 
connected to the same network as the node. 



wo 01/97447 



-7- 



CT/SEOl/01301 



BRIEF DESCRIPTION OF THE DRAWINGS 
The objects and advantages of the invention will be understood by reading the 
following detailed description in conjunction with the drawings in which: 
FIG. 1 illustrates an exenoplary piconet; 
FIG. 2 illustrates an exetoplary star-topology network; 
FIG. 3 illustrates an exenoplary scatternet formed by a plurality of piconets; 
FIG. 4 illustrates a conventional Bluetooth packet; 

FIG. 5 illustrates signalling between two nodes for neighbor discovery and connection 
establishnaent; 

FIG. 6 illustrates a conventional FHS packet; 

FIGS. 7A-7C illustrate exenq>lary methods for selecting a scatternet ID in accordance 
with the present invention; 

FIGS. 8 A and 8B illustrate exemplary methods for selecting a scatternet ID in 
accordance with another embodiment of the present invention; 

FIG. 9 illustrates an exenq)lary method for selecting a scatternet ID when a node 
receives a change-scattemet-ID-message in accordance with one embodiment of the present 
invention; 

FIG. 10 illustrates another exemplary method for selecting a scatternet ID when a node 
receives a change-scattemet-ED-message in accordance witibi another embodiment of the present 
invention; 

FIGS. IIA and IIB illustrate exenq>lary methods for selecting a scatternet ID in 
accordance with yet another exemplary embodiment of the present invention. 

FIG. lie illustrates an exemplary method for reception and processing of a change- 
scattemet-ED-message in accordance with exemplary embodiments of the present invention; 

FIG. 12 illustrates an exemplary method for periodically selecting a scatternet ID in 
accordance with one embodiment of the present invention; 

FIG. 13 illustrates an exemplary scatternet in accordance with the present invention; 

FIG. 14 illustrates an exemplary method for selecting a scatternet ID when a node has 
broken a connection with a node of another piconet in accordance with another exemplary 
embodiment of the present invention; and 

FIG. 15 illustrates an exemplary Bluetooth imit in accordance with the present 
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invention. 

DETAILED DESCRIPTION 

The present invention is directed to ad-hoc networks. More particularly, the present 
invention is directed to obtaining topology information related to an ad-hoc network. 

In dynamic networks such as ad-hoc networks keeping track of the detailed topology of 
a scatternet, i.e. , the exact connections that each node in the scatternet has with other nodes in 
the scatternet, would be too demanding. Further, as a scatternet grows, tracking of the 
detailed topology of a scatternet becomes increasingly complex. In accordance with exemplary 
enabodiments of the present invention, nodes only keep track of which scatternet a particular 
node belongs to, so that it can easily be determined whether two nodes belong to the same 
scatternet, without knowing anything about the connection structure between them. This 
reduces the topology of a scatternet to the "cloud" stage, i.e., a cloud being a commonly used 
symbol to represent a network with arbitrary topology. 

In accordance with exemplary embodiments of the present invention each scatternet has 
a randomly chosen scatternet identity (scatternet ID) which is known by each node in the 
scatternet. When responding to an INQUIRY message, a node will include the scatternet ID in 
the INQUIRY RESPONSE message, e.g. , in the class of device field. The inquiring node then 
knows that the node from which it has received an INQUIRY RESPONSE message is 
reachable via all other nodes that respond witib the same scatternet ID. By collecting 
INQUIRY RESPONSE messages including different scatternet IDs, the inquiring node obtains 
a picture of the different "scattemet islands" that are present in the vicinity of the particular 
node. In accordance with exemplary embodiments of the present invention, an idle node, i.e., 
a node that is not connected to any other node, should respond with a default scatternet ID, 
e.g., all zeros, reserved for this purpose. Alternatively, the idle status could be indicated 
explicitly by some other means, e.g. , using the xmdefined field of the FHS packet. In such 
case, an idle node would not have to include any scatternet ID at all in the INQUIRY 
RESPONSE message. 

In the following description references are made to neighbor nodes of a particular node. 
One skilled in the art will recognize that there are two types of neighbor nodes, those which 
are connected to the particular node (i.e., part of the same piconet or scatternet) and those 
which are within radio range of the particular node but does not have an established connection 
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with the particular node. Accordingly, it will be recognized that in the following when it is 
described that a message is forwarded to a neighbor node, this neighbor node is a connected 
neighbor node. Further, it will be recognized that when it is described that the particular node 
is performing a process to determine which network a neighbor node belongs to, this neighbor 
node is within radio range but does not have an established connection with the particular 
node. This will be evident because if the particular node and the neighbor node have an 
established connection, the particular node will already know which network the neighbor 
node belongs to. 

FIG. 7A illustrates an exemplary method for selecting a scattemet ID in accordance 
with the present invention. When a piconet is furst established between a master node and a 
slave node, the piconet does not have a scattemet ID. Accordingly, the noiaster of the piconet 
chooses a scattemet ID at random (Step 710). The master then transfers the scattemet ID to 
the slave (Step 720). 

If a new node joins the piconet, this node may be a single node (i.e. , idle) or the new 
node can be connected to another scattemet or piconet, where a single piconet is a trivial case 
of the more general scattemet concept. In the former case, the scattemet ID should be 
transferred to the new node. In the latter case two scattemets have been merged and one of 
their respective scattemet IDs has to be selected as the scattemet ID for ihe new merged 
scattemet. Accordingly, it is determined whether a new node has joined the scattemet (Step 
730). If a new node has not joined the scattemet ( "NO" path out of decision Step 730), then 
the nodes of the piconet continue to wait (Step 740). If, however, a new node joins the 
scattemet ("YES" path out of decision Step 730), then it is detemiined whether the new node 
was previously idle (Step 745). An idle node is not a member of a scattemet, and hence, does 
not have a scattemet ID. If the new node was previously idle ("YES" path out of decision 
Step 745) then the scattemet ID is transferred to the new node (Step 747). If the new node is 
not an idle node then the new node is a member of another scattemet and the scatternets are 
merged (Step 750). 

If the size of the scattemets are available ("YES" path out of decision Step 760), then 
the scattemet ID of the larger scattemet is selected as the scattemet ID of the merged 
scattemets (Step 770). A change-scattemet-ID-message is then broadcast through the 
scattemet whose scattemet ID was not selected, i.e., the change-scattemet-ID-message is 
forwarded between nodes until the message has reached all the nodes in the scattemet/network 
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(Step 790). If, however, the size of the scattemets is not available ("NO" path out of decision 
Step 760) then the scattemet ID of either of the two nodes forming the connection that merges 
the two scattemets could be chosen. An arbitrary rule could be selected for this choice, e.g., 
that the scattemet associated with the joining node is selected (Step 780), wherein the "joining 
node" is the node assuming the slave role in the connection merging the scattemets. When a 
scattemet ID has been selected a change-scattemet-ID-message is then broadcast through the 
scattemet whose scattemet ID was not selected (Step 790). 

The method illustrated in FIG. 7A is an advantageous way of selecting a scattemet ID. 
Since the scattemet ID of the scattemet with the larger number of nodes is selected the change- 
scattemet-ID-message only has to be broadcast through the smaller scattemet, tibius resulting in 
less load being placed on the ad-hoc network. However, such size information may not be 
generally available. Further, when a change-scattemet-ID-message is broadcast due to a 
merger of two scattemets, there is a slight risk that a merger with another scattemet, or several 
scattemets, is being performed simultaneously. This could result in colliding of change- 
scattemet-ID-messages, i.e., multiple change-scattemet-ID-messages being distributed through 
the scattemet simultaneously. Further, a scattemet could be merging with another scattemet 
via two different connections, i.e., between the same two scattemets, simultaneously. This 
could result in either colliding or looping of change-scattemet-ID-messages. Accordingly, it 
would be desirable to provide a mechanism to control these situations, i.e., a mechanism of 
how to establish which scattemet ID has precedence over the other scattemet ID. This 
mechanic would govem the way a node acts whenever it has to choose between scattemet 
IDs, e.g., when it receives a change-scattemet-ID-message and already has a stored scattemet 
ID. The mechanism would instract the node whether it should replace the stored scattemet ID 
with one received in the change-scattemet-ID-message or retain its stored scattemet ID and 
discard the new one it received. 

One way to address this situation is to provide a mechanism that a node always chooses 
the highest scattemet ID, between the scattemet ID received in the change-scattemet-ID- 
message and the stored scattemet ID. However, this mechanism has the drawback that with 
every scattemet ID change the scattemet ID will be driven towards the highest value in the 
scattemet ID range. This will result in an accumulation of scattemet IDs in the upper part of 
the scattemet ID range, thereby reducing the randomness and increasing the risk that two 
scattemets choose flie same scattemet ID. To avoid such accumulation, a rule must not tend to 
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drive the scattemet ID towards any particular value in the scattemet ID range. Further, the 
chosen value should still be completely arbitrary and every part of the scattemet ID range 
should be equally probable. 

FIGS. 7B and 7C illustrate alternative methods for selecting a scattemet ID. Whereas 
in FIG 7A the scattemet ID can be selected based upon the size of the scattemet or based upon 
which node is the joining node, the method can be implemented such that the scattemet ID is 
selected solely based upon which node is the joining node (FIG. 7B), or solely based upon the 
size of the scattemet (FIG. 7Q. It will be recognized that if the selection of the scattemet ED 
is based solely upon the size of the scattemets, the size of the scattemets will always be 
available, and hence, the method illustrated in FIG. 7C does not need to determine whether 
scattemet size is available (Step 760 in HG. 7A). 

FIG. 8A illustrates an exemplary method for selecting a scattemet ID when two 
scattemets have been merged, without reducing the randomness of the selected scattemet ID 
and without driving the scattemet ID towards any particular value in the scattemet ID range. 
It is &st determined whether a new node has joined the scattemet (Step 805). If a new node 
has not joined the scattemet ("NO" path out of decision Step 805) then the method loops back 
to decision Step 805 and waits for a new node to join the scattemet. If a new node has joined 
the scattemet ("YES" patii out of decision Step 805) then it is determined whether the new 
node was previously idle (Step 806). If the new node was previously idle ("YES" path out of 
decision Step 806) then the scattemet ID is transferred to the new node (Step 807). If the new 
node was not previously idle (""NO" path out of decision Step 806) then the scattemets are 
merged (Step 810). The nodes then exchange their scattemet IDs (Step 815). Each node then 
determines whether the received scattemet ID is the same as tiie stored scattemet ID (Step 
820). If the received scattemet ID is the same as the stored scattemet ID ("YES" pafli out of 
decision Step 820) then the processing in the node ends (Step 825). 

If the scattemet ID is not the same as the stored scattemet ID ("NO" path out of 
decision Step 820) then an "Exclusive OR" (XOR) operation is performed using the least 
significant bit (LSB) of the received scattemet ID and the current scattemet ID (Step 830). If 
the result of the XOR operation is 0 ("YES" path out of decision Step 835) then the node will 
determine that the lower scattemet ED has precedence over the higher scattemet ID (Step 840). 
If, however, the result of the XOR operation is not equal to 0 ("NO" path out of decision Step 
835) then the node will detemune that the higher scattemet ID has precedence over the lower 
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scattemet ID (Step 845), 

After it has been determined which scattemet ID has precedence over the other (Step 
840 or Step 845) it is determined whether the received scattemet ID has precedence over the 
old scattemet ID (Step 850). If the received scattemet ID has precedence over the old 
scattemet ID ("NO" path out of decision Step 850) then the processing for the node ends (Step 
855). If, however, the received scattemet ID does not have precedence over the old scattemet 
ID ("YES" path out of decision Step 850) then the node sends the new scattemet ID in a 
change-scattemet-ID message to the new node (Step 860). In FIG. 8A the dashed lines 
returning to step 805 illustrate that the method illustrated in HG. 8A is performed by nodes as 
a continuous process. 

It will be recognized in the method described above in connection with FIG. 8A that 
the exchanging of scattemet IDs by the nodes (Step 815) and the sending of a change- 
scattemet-ID-message to the new node which is to have its scattemet IDs replaced (Step 860) 
is separated by a period of time. If one or both of these scattemet IDs are changed in between 
these two operations problems may result. Further, when a node participating in more than 
one piconet switches between these piconets the length of time between the above-described 
operations can be significant. To help illustrate this problem, a brief example of a situation in 
which this problem can occur is presented. 

Assume that node A in scattemet A connects to node B in scattemet B. The two nodes 
then exchange scattemet IDs (Step 815) by using means other than the above described change- 
scattemet'ID-message, for example, by using some type of message dedicated for this purpose. 
Further assume, that the scattemet ID of node B has precedence over the scattemet ID of node 
A as a result of the XOR operation (Step 830 through Step 845). Accordingly, node A win 
wait for a change-scattemet-ID-message from node B. Assume diat while node B is preparing 
to send a change-scattemet-ID-message to node A, node B receives a change-scattemet-ID- 
message from its old scattemet, i.e., scattemet B, that takes precedence over the current 
scattemet ID of node B. If this new scattemet ID does not take precedence over the scattemet 
ID of node A, then when node B forwards the change-scattemet-ID-message to node A, node 
A will discard the change-scatternet-ID-message and keep its old scattemet ID. This results in 
the two old scattemets, although now merged into one, still having different scattemet IDs. 

FIG. 8B illustrates an exemplary method for selecting a scattemet ID when two 
scattemets have merged which addresses the above described problems. Accordingly, 
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whereas in FIG. 8A the nodes exchange scatteraet IDs using means other than a change- 
scattemet-ID-inessage (Step 815), in FIG. SB this step is replaced by a step where a node 
sends a change-scattemet-ID-message to the new node and receives a change-scatternet-ID- 
message from the new node (Step 817). When these change-scattemet-DD-messages are 
received they are processed in the same way as any received change-scattemet-ID-naessage, 
which effectively means that the exchanging of scattemet IDs and the replacement of one of 
the scattemet IDs are achieved with the same message, i.e., without time separation. 
Further, when the received scattemet ID is the same as the stored scattemet ID, the change- 
scattemet-ID-message is discarded (Step 826). 

Another difference between the procedures illustrated FIG 8A and FIG 8B is the 
procedure following the determination of the result of the XOR operation on the least 
significant bit of the two scattemet IDs, i.e., decision Step 835. In FIG 8A the node just 
determines which of the two scattemet IDs that has precedence over the other (Step 840 or 
845) without replacing the old scattemet ID irrespective of the result of this determination. 
If the stored scattemet ID has precedence over the received scattemet ID, the node sends a 
change-scattemet-ID-message including the stored scattemet ID to the other node (Step 
860). The actual replacement of scattemet ID will occur when this change-scattemet-ID- 
message is received unless the above described problem occurs. 

In contrast, in the procedure illustrated in FIG 8B, based on the result of the XOR 
operation (decision Step 835) the node selects one of the scattemet IDs to be the new one 
(Steps 841 or 846) and if the received scattemet ID is selected, the old scattemet ID is 
replaced by die received scattemet ID and the change-scattemet-ID-message is forwarded to 
other nodes in the original scattemet of the node (Step 851 and 861). On the other hand, if 
the received scattemet ID is not selected as the new scattemet ID, the node keeps the old 
scattemet ID and discards the change-scattemet-ID-message. By sending a change- 
scattemet-ID-message to the new node and receiving a change-scattemet-ID-message from 
the new node (Step 817) the problems described above in connection with FIG. 8 A are 
avoided because the exchanging of scattemet IDs and the replacement of scattemet ID are 
effectuated by the same message, i.e. without separation of the two steps. It wiU be 
recognized that in FIG. 8B the dashed lines returning to step 805 illustrate that the method 
illustrated in FIG. 8B is performed by nodes as a continuous process. 

FIG. 9 illustrates the exemplary behavior of a node which has received a change- 
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scattemet-ID-message. The node determines whether it has received a change-scattemet- 
ID-message (Step 905). If a node has not received a change-scattemet-ID-message ("NO" 
path out of decision Step 905) the node continues to wait to receive a change-scattemet-ID- 
message. If, however, the node has received a change-scattemet-ID-message ("YES" path 
out of decision Step 905) the node determines whether the received scattemet ID is the 
same as the stored scattemet ID (Step 910). If the received scattemet ID is the same as the 
stored scattemet ID ("YES" path out of decision Step 910) the node will discard the 
change-scattemet-ID-message (Step 915). If the received scattemet ID is not the same as 
the stored scattemet ID ("NO" path out of decision Step 910) then the node performs an 
XOR operation using the least significant bit from the scattemet ID in the message and the 
current stored scattemet ID (Step 920). 

If the result of the XOR operation is equal to 0 ("YES" path out of decision Step 
925) the node will select the lower scattemet ID as the new scattemet ID (Step 930). If the 
result of the XOR operation is not equal to 0 ("NO" path out of decision Step 925) then the 
node will select the higher scattemet ID as the new scattemet ID (Step 935). Once either 
the lower scattemet ID or the higher scattemet ID has been selected (in accordance with 
either Step 930 or Step 935) then the node determines whether the received scattemet ID 
has replaced the old scattemet ID (Step 940). If the received scattemet ID has not replaced 
the old scattemet ID ("NO" path out of decision Step 940) then the node keeps the old 
scattemet ID and discards the change-scatternet-ID-message (Step 945). If, however, ttie 
received scattemet ID has replaced the old scattemet ID ("YES" path out of decision Step 
940) then the node stores the new scattemet ID and forwards the change-scattemet-ID- 
message to all connected nei^bor nodes except the one from which the change-scattemet- 
ID-message was received (Step 950). 

FIG. 10 illustrates another exemplary behavior of a node which has received a 
change-scattemet-ID-message. In accordance with this embodiment of the present 
invention, a timestamp, representing the time when the scattemet ID was generated, is 
associated with each scattemet ID. This timestamp is included in the change-scattemet-ID- 
message together with the new scattemet ID. A node which receives a change-scattemet- 
ID-message con^ares the received timestamp with a timestamp associated with the stored 
scattemet ID. 

Initially, a node determines whether it has received a change-scattemet-ID-message 
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(Step 1005). If the node has not received a change-scattemet-ID-message ("NO" path out 
of decision Step 1005) then the node waits until it has received a change-scattemet-ID- 
message. If a node has received a change-scattemet-ID-message ("YES" path out of 
decision Step 1005) then the node determines whether the scattemet ID in the received 
message is the same as the stored scattemet ID (Step 1010). If the received scattemet ID is 
the same as the stored scattemet ID ("YES" path out of decision Step 1010) then the 
received message is discarded (Step 1015). 

If the received scattemet ID is not the same as the stored scattemet ID ("NO" path 
out of decision Step 1010) then the node conq)ares the received timestamp with the stored 
timestamp (Step 1025). If the timestamps are the same ("YES" path out of decision Step 
1030) then the node performs an XOR operation using the least significant bit of the 
scattemet ID in the message and the current scattemet ID (Step 1050) . If the timestamps 
are not the same ("NO" path out of decision Step 1030) then the node determines whether 
the received timestamp is newer than the stored timestamp (Step 1035). If the received 
timestamp is not newer than the stored timestamp ("NO" path out of decision Step 1035), 
i.e., indicating that the stored timestamp is "fresher" than the received timestamp, then the 
node will discard the message (Step 1015). If, however, the received timestamp is newer 
than the stored timestamp ("YES" path out of decision Step 1035) then the node replaces 
the stored scattemet ID with the received scattemet ID (Step 1040). The node will then 
forward the change-scattemet-ID-message to all connected neighbor nodes except the one 
from which the change-scattemet-ID-message was received (Step 1045). 

If the timestamps are the same ("YES" path out of Step 1030) and the node has 
performed an XOR operation using the least significant bit of the scattemet ID in the 
message and the current scattemet ID (Step 1050) then the node will determine the result of 
the XOR operation (Step 1055). If the result of the XOR operation is equal to 0 ("YES" 
path out of decision Step 1055) the node selects the lower scattemet ID as the new 
scattemet ID (Step 1060). If the result of the XOR operation is not equal to 0 ("NO" path 
out of decision Step 1055) the node will select the higher scattemet ID as the new scattemet 
ID (Step 1065). 

Once the node has selected the higher scattemet ID (Step 1065) or the lower 
scattemet ID (Step 1060), the node determines whether the received scattemet ID has 
replaced the old scattemet ID (Step 1070). If the received scattemet ID has not replaced 
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the old scattemet ID ("NO" path out of decision Step 1070) then the node keeps the old 
scattemet ID and discards the change-scattemet-ID-message (Step 1075). If, however, the 
received scattemet ID has replaced the old scattemet ID ("YES" path out of decision Step 
1070) then the node stores the new scattemet ID and forwards the change-scattemet-ID- 
message to all connected neighbor nodes except the one from which the change-scattemet- 
ID-message was received (Step 1080). 

The timestamp method illustrated in FIG. 10 helps avoid colliding or looping of 
change-scattemet-ID-messages because when a node receives a change-scattemet-ID- 
message with a timestamp which is older than the stored timestamp associated with the 
node's current scattemet ID (Step 103S) the node discards the received change-scattemet- 
ID-message. Accordingly, older scattemet IDs contained in change-scattemet-ID-messages 
are prevented from propagating throughout the remainder of the scattemet. 

A corollary to the selection of a single scattemet ID when two separate scattemets 
merge, is that when a single scattemet is split, the two resulting scattemets should each 
have a different scattemet ID. FIGS. IIA and IIB illustrate exemplary methods of 
periodically generating and propagating new scattemet IDs throughout a scattemet, thereby 
ensuring if a scattemet has broken oif of the current scattemet that the original scattemet 
and the broken off scattemet will have different scatterent IDs. Preferably, only the master 
nodes periodically generate and distribute scattemet IDs. This spares the slave nodes from 
this burden and reduces the risk of colliding messages distributing periodically generated 
scattemet IDs. However, it would be quite possible to let all the nodes periodically 
generate and distribute new scattemet IDs. In addition to handling the split scattemet case, 
the periodical generation and distribution of new scattemet IDs also work as a general 
"safety net" procedure which cleans up fault conditions that may occur during the 
management of scattemet IDs. 

Accordmg to the method illustrated in FIGS. IIA and IIB, master nodes, but not 
slave nodes, will periodically generate and broadcast new random scattemet IDs. 
Accordingly, each node determines whether it is a master node (Step 1105). If a node is 
not a master node ("NO" path out of decision Step 1105) then the processing for that node 
ends (Step 1110). If a node is a master node ("YES" path out of decision Step 1105) then 
the node randomly chooses a time value between a predefined Tninitmini value TO and a 
predefined maximum value Tl (Step 1115). The node then starts a timer (Step 1120). 
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If the timer has not exceeded the random time value ("NO" path out of decision Step 
1 125) then the node determines whether a new scattemet ED has been received and whether 
the stored scattemet ID has changed since the timer was started (Step 1130). If a new 
scattemet ID has been received and the stored scattemet ID has been changed since the 
timer was started ("YES" path out of decision Stqp 1130) then the node randomly chooses a 
time value (Step 1 1 15). If, however, a new scattemet ID has not been received and the 
stored scattemet ID has not been changed since the timer was started ("NO" path out of 
decision Step 1130) the node continues to determine whether the timer has exceeded the 
random value (Step 1125). If the timer exceeds the random time value ("YES" path out of 
decision Step 1125) then the node generates a new random scattemet ID (Step 1135). 

The differences between the procedures illustrated in FIGS. IIA and 1 IB is the type 
of message distributed by the master node after the master node has generated a new 
random ID (Step 1135). In accordance with the method illustrated in FIG. IIA after the 
master node has generated a new random ID (Step 1135) the master node distributes the 
new ID in a change-scatternet-ED-message (Step 1140) and then returns to randomly choose 
a time value (Step 1115). A node which receives the new ID in the change-scattemet-ID- 
message generated using the method described in connection with FIG. IIA would perform 
an XOR operation on the least significant bit of the scattemet ID in the message and the 
current ID as described in above in connection with FIGS. 8A or 8B, i.e.. Steps 830-860 of 
FIG. 8A or Steps 830-862 in FIG. 8B. Alternatively, if the timestamp method described in 
connection with FIG. 10 is used, a node receiving the change-scattemet-ID-message 
generated using the method described in connection with FIG. 1 1 A would follow steps 
1010-1080 in FIG. 10. 

In the method illustrated in FIG. IIB after generating a new random ID (Step 1 136) 
the master node distributes the new ID in a periodically-changed-scattemet-ID-message 
(Step 1142) and then returns to randomly choose a time value (Step 1115). The differences 
between a change-scattemet-ID-message and a periodically-changed-scattemet-ID-message 
is the procedures followed by a node which receives the particular message. It should be 
noted that the procedure described in coimection with IIB can be used only if the 
timestamp method is used, i.e., if the procedure described in connection with FIG. 10 is 
used for reception of regular change-scattemet-ID-messages. 

FIG. lie illustrates the procedures performed by a node which receives a 
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periodically-clianged-scatteriiet-ID-message. Initially, the node detennines whether it has 
received a periodically-changed-scattemet-ID-message (Step 1145). If the node has not 
received a periodically-changed-scattemet-ID-message ("NO" path out of decision Step 
1145) then the node continues to wait until it receives such a message. If the node does 
receive a periodically-changed-scattemet-ID-message ("YES" path out of decision Step 
1145) the node con[q)ares the timestamp in the received message with the stored timestamp 
(Step 1150) and the node determines wheflier the timestamps are the same (Step 1155). If 
the node determines that the timestamps are the same ("YES" path out of decision Step 
1155) the node uses the XOR method to select a scattemet ID (Step 1160) as described 
above in connection with FIGS. 8-10, i.e., St^s 830-861 of FIG, 8B; Steps 920-950 of 
HG. 9; and Steps 1050-1080 of FIG. 10 with the only difference being that the message to 
be either discarded or forwarded is a periodically-change-scattemet-ID-message instead of a 
regular change-scattemet-ID-message. 

If it is determined that the timestamps are not the same ("NC path out of decision 
Step 1155) then the node determines whether the differences between the timestamps is less 
than a time period TO (Step 1162), wherein TO is the shortest time that the timer governing 
periodical generation of new scattemet IDs can be set to. If the differences between the 
timestamps is less than TO (**YES" patibi out of decision step 1162) then it is determined 
whether the received timestanop is older than the stored timestamp (Step 1164). If the 
received timestamp is not older than the stored timestamp C^NO" path out of decision Step 
1164) then the node discards the message (Step 1166). If the received timestamp is older 
than the stored timestamp (""YES" path out of decision Step 1164) then the node replaces 
the stored scattemet ID with the received scattemet ID (Step 1175) and forwards the 
periodically-changed-scattemet-ID-message (Step 1180). 

If the differences between the timestamps is not less than the time period TO ("NO" 
path out of decision Step 1162) then the node determines whether the received timestamp is 
newer than the stored timestamp (Step 1168). If the received timestamp is not newer than 
the stored timestamp ("NO" path out of decision Step 1168) then the node discards the 
message (Step 1170). If, however, the received timestamp is newer than the stored 
timestamp ("YES" path out of decision Step 1168) then the node replaces the stored 
scattemet ID with the received scattemet ID (Step 1175) and forwards the periodically- 
changed-scattemet-ID-message (Step 1180). 
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It will be recognized that using the periodically-changed-scattemet-ID-message 
described in connection with FIGS. IIB and IIC results in the scattemet ID in the 
periodically-changed-scattemet-ID-message replacing the stored scatternet ED. Further, in 
cases of colliding periodically-changed-scattemet-ID-messages, the message with the oldest 
of the two timestamps will prevail because this scattemet ID will likely have spread over a 
larger part of the scatternet. 

FIG. 12 illustrates an exeniplary method for generating a new random ID when only 
the XOR method (without timestamps) is used. The procedure described in connection 
with FIG. 11 A governs when to generate a new random scattemet ID and the procedure 
described in connection with FIG. 9 is used when a node receives a change-scatternet-ED- 
message. The method illustrated in FIG. 12 provides the details of Step 1135 in FIG. 11 A. 
In accordance with the method illustrated in FIG. 12 a fraction F is chosen such that 
1/2'*^F^ where n is the number of bits in the scattemet ED. As will be described in 
more detail below the fraction F is used in the generation of new random scattemet IDs to 
prevent these random scattemet IDs from being chosen from a too small part of the total 
scattemet ID range, which would degrade the random properties of the scattemet ID. 
Accordingly, a node first determines whether the stored scatt^et ID is in the lowest F 
fraction of the range of scattemet ID (Step 1243). If the stored scattemet ED is in the 
lowest F fraction of the range of scattemet ID ("YES" path out of decision Step 1243) the 
node will set tiie least significant bit of the new scattemet ID to the inverted value of the 
least significant bit of the stored scattemet ID (Step 1246). Next the node will randomly 
select the remaining bits of the new scattemet ID in the range above the stored scattemet ID 
(Step 1249). 

If the stored scattemet ED is not in the lowest F fraction of its range ("NO" path out 
of decision Step 1243) then the node determines whether the stored scattemet ID is in the 
highest F fraction of the range of scattemet IDs (Step 1252). If the stored scattemet ID is 
in the highest F fraction of the range of scattemet IDs ("YES" path out of decision Step 
1252) then the node sets the least significant bit of the new scattemet ID to the same value 
as the least significant bit of the stored scattemet ID (Step 1255). Next the node randomly 
selects the remaining bits of the new scattemet ID in the range below the stored scattemet 
ID (Step 1258). 

If the stored scattemet ID is not in the highest F fraction of the range of scattemet 
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IDs ("NO" path out of decision Step 1252) then the node randomly chooses the least 
significant bit of the new random ID to be either a 1 of a 0 (Step 1261). Next the node 
perfonns an XOR operation using the randomly chosen least significant bit with the least 
significant bit of the stored scatternet ID (Step 1264). If the result of the XOR operation is 
0 ("NO" path out of decision Step 1267) then the node randomly selects the remaining bits 
of the new scatternet ID in the range below the stored scatternet ED (Step 12S8). If, 
however, the result of the XOR operation is 1 ("YES" path out of decision Step 1267) then 
the node randomly selects the remaining bits of the new scatternet ID in the range above 
the stored scatternet ID (Step 1249). It will be recognized that when F== 1/2 that the 
scatternet ID will satisfy eith^ step 1243 or step 12S2, and hence, steps 1261-1267 would 
not be needed. 

Another way of dealing with the problem of keeping the scatternet IDs unique in 
case of a split scatternet is to try to detect when a scatternet is split into two separate 
scatternets and then generate a new scatternet ID in one of the separate scattemets. A 
scatternet split is always caused by the breaking of a connection between two nodes. If the 
broken connection was the only connection between two parts of the scatternet, the broken 
connection results in two separate scattemets. However, a broken coimection does not 
always split a scatternet. Other connections may still hold all the nodes together and in 
such case they are still a single scatternet. Since a broken connection between two nodes of 
a scatternet does not necessarily indicate the formation of two separate scattemets, it would 
be advantageous to be able to detemoine whether in fact two scattemets have been formed 
as a result of the split between the two nodes. For example, referring now to FIG. 13, if 
connection 1305 between nodes 1310 and 1320 were broken, the two nodes would not be 
able to communicate with each other directly over link 1305. However, nodes 1310 and 
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1405) the node continues to make this determination. If the node determines that it has 
broken a connection with another node ("YES" path out of decision Step 1405) the node 
determines whether the node is now idle (Step 1407). If the node is now idle ("YES" path 
out of decision step 1407) then processing for the node ends (Step 1408). If the node is not 
idle ("NO" path out of decision step 1407) then the node determines whether it has a lower 
BD_ADDR than the node with which there was a broken connection (Step 1410). If the 
node does not have a lower BD_ADDR than the node with which there was a broken 
connection ("NO" path out of decision Step 1410) the node sets a timer (Step 1412) and 
waits for a message from the other node of the broken coimection (Step 1415). The node 
with the higher BD_ADDR then determines whether it has received a message from the 
node with the lower BD_ADDR (Step 1420). If the node with the higher BD^ADDR has 
not received a message from the node with the lower BD_ADDR ("NO" path out of 
decision Step 1420) then the node determines whether the timer has expired (Step 1422). If 
the node determines that the timer has expired ("YES" path out of decision step 1422) then 
the node concludes that the scattemet has been split (Step 1424). If the timer has not 
expired ("NO" path out of decision step 1422) then the node continues to wait to receive 
the message (Step 1415). If, however, the node with the higher BD_ADDR has received a 
message from the node with the lower BD_ADDR ("YES" path out of decision Step 1420) 
the node with fbe higher BD ADDR sends a reply message to the node with the lower 
BD_ADDR (Stqp 1425). Accordingly, these two nodes will now know that although there 
is no longer a direct link between them, i.e., a link with zero hops, they are still part of the 
same scattemet. 

An alternative to steps 1412-1425 is that the processing in the node with the higher 
BD__ADDR ends with the "NO" path out of decision step 1410. If a message is 
subsequently received from the node with the lower BD_ADDR, the node with the higher 
BD ADDR would still send a reply message to the node with the lower BD ADDR, not 
because the node with the higher BD ADDR was waiting for the message from the node 
with the lower BD_ADDR, but because the message from the node with the lower 
BD_ADDR was a type of message that should always be replied to by the intended 
receiver, e.g. a route request message. In this alternative the node with die higher 
BD^ADDR nught not determine whether the scattemet was split or not by the broken 
connection. 
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If the node detennines it has a lower BD_ADDR than the node with which there 
was a broken connection ("YES" path out of decision Step 1410) the node sends a message 
to the other node (Step 1430). For example, the message can be a request for route 
message to the other node. The node then sets a timer (Step 1435) and determines whether 
it has received a reply message from the other node (Step 1440). If the node has received a 
reply message from the other node ("YES" path out of decision Step 1440) then the node 
knows that the other node is part of the same scattemet and the node ends its current 
processing (Step 1445). If, however, the node does not receive a reply message from the 
other node ("NO" path out of decision Step 1440) the node determines whether the timer 
has expired (Step 1450). If the node determines that the timer has not expired ("NO" path 
out of decision Step 1450) then the node continues to determine whether it has received a 
reply message from the other node (Step 1440). If the node detennines that the timer has 
expired ("YES" path out of decision Step 1450) then the node determines that the scattemet 
has been split and generates a new random scattemet ID (Step 1455). The new scattemet 
ID is then transferred to connected neighboring nodes in a change-scattemet-ID-message 
(Step 1460). 

FIG. 15 illustrates an exemplary apparatus for implementing the methods described 
above. The apparatus includes antenna 1510, transceiver 1520 and processor 1530. As 
described above, ad-hoc networking nodes, and Bluetooth units in particular, can be 
embodied in various forms. Accordingly, the apparatus illustrated in FIG. 15 could be a 
mobile telephone, a personal digital assistant (PDA), a router, a printer, a kitchen 
appliance, or any other device for which it would be advantageous to form wireless 
networks. Further, altiiough FIG. 15 illustrates processor 1530, one skilled m the art wiU 
recognize that this apparatus can be iinplemented with either a microprocessor, an 
application specific integrated circuit (ASIC), hard-wired logic, or any other equivalent 
means. 

Although the present invention has been described above in one embodiment as one 
node using a scattemet ID to determine whether another is part of the same scattemet, it 
will be recognized that there are many other uses for the scattemet ID, For example, one 
node may broadcast the scattemet ID in a neighbor discovery message and compare the 
responses received from neighboring nodes. Based upon the comparison of the responses 
the one node can determine whether the responding nodes are part of the same scattemet. 
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This information can be used by the one node to determine that if it connects to one of the 
responding nodes, the one node will also be able to reach the other responding node 
because they are part of the same scattemet. 

The present invention has been described with reference to several exemplary 
embodiments. However, it will be readily apparent to those skilled in the art that it is 
possible to embody the invention in specific forms other than those of the exemplary 
embodiments described above. This may be done without departing firom the spirit of the 
invention. These exenq)lary embodiments are merely illustrative and should not be 
considered restrictive in any way. The scope of the invention is given by the appended 
claims » rather than the preceding description, and all variations and equivalents which fall 
within the range of the clainois are intended to be embraced therein. 
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WHAT IS CLAIMED IS: 

1. In an ad-hoc network including a first node which belongs to a first network, 
a method for determining a network which a second node belongs to, the method 
comprising the steps of: 

transmitting from the first node a neighbor discovery message; 

receiving from the second node a neighbor discovery response message, wherein the 
neighbor discovery response message inchides an identification of a network which the 
second node belongs to; and 

determining which network the second node belongs to using the identification. 

2. The method of claim 1, wherein the step of determining further comprises 
the steps of: 

comparing the identification received from the second node with an identification 
stored in the first node; 

determining that the second node belongs to a different network if the received 
identification does not match the stored identification. 

3. The method of claim 1, wherein the ad-hoc network is a wireless network. 

4. The method of claim 1 , wherein the ad-hoc network operates according to 
Bluetooth protocol. 



5. In an ad-hoc network a method for selecting a network identification 
comprising the steps of: 

selecting by a first node a random network identification; 

transferring from the first node to a second node the random network identification; 
determining by the second node whether to adopt the random network identification; 

and 

sending a new network identification message if the second node adopts the random 
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network identification. 

6. The method of claim 5, wherein the second node adopts the random network 
identification if a size of a network associated with the random network identification is 
larger than a size of a network associated with the second node. 

7. The method of claim S, wherein the step of determining conq)rises the steps 

of: 

performing an exclusive OR operation using a least significant bit of the random 
network identity and a least significant bit of a network identity associated with the second 
node; and 

selecting the higher network identity if a result of the exclusive OR operation has a 
value of one. 

8. The method of claim 5, wherein the step of determining comprises the steps 

of: 

comparing a timestamp associated with the random network identity and a 
timestamp associated with a network identity associated with the second node; and 
selecting the network identity with the newer timestamp. 

9. The method of claim 3 , wherem the step of determining comprises the steps 

of: 

determining whether a message which contains the random network identity is a 
periodic change of identification message; 

comparing a timestamp associated with the random network identity and a 
timestamp associated with a network identity of the second node; 

detenniniag whether the timestamp associated with the random network identity is 
less than a predetermined amount of time different than the timestamp associated with the 
network identity of the second node; 

if the timestamp associated with the random network identity is less than a 
predetermined amount of time different than the timestamp associated with the network 
identity of the second node, selecting the network identity with the older timestan^ if the 
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message is a periodic change of identification message 

if the timestamp associated with the random network identity is greater than a 
predetermined amount of time different than the timestamp associated with the network 
identity of the second node, selecting the network identity with the newer timestamp if the 
message is a periodic change of identification message. 

10. The method of claim 5, wherein the step of selecting comprises the steps of: 
determining whether the first node has broken a connection with another node; 
determining whether the first node has a Iowct address than the another node; 

if the first node has broken a connection with the another node and the first node lias 
a lower address, the first node performs the following steps 
sending a message to the another node; 
setting a timer; 

determining whether the first node has received a response firom the another 

node; and 

generating a new random network identification if the first node has not 
received a response fi:om the another node. 

11. In an ad-hoc network a method for selecting a network identification 
comprising the steps of: 

starting a timer;: 

randomly selecting a time value; 

generating a new random network identification if the tuner exceeds the randomly 
selected time value; and 

distributing the new network identification to other nodes in the ad-hoc network. 

12. The method of claim 11, wherein the new network identification is 
distributed in a message which includes an indication that the new network identification is 
a periodically generated network identification. 
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13. In an ad-hoc network including a first node which belongs to a first network, 
a method for determining whether a second node belongs to the first network, the method 
comprising the steps of: 

determining in the first node whether a connection with the second node has been 
broken; 

sending a message from the first node to the second node through the ad-hoc 
network; 

setting a timer in the first node; and 

determining that the second node does not belong to the first network if the first 
node does not receive a reply firom the second node before the e;qpiration of the timer. 

14. The method of claim 13, wherein if it is determined that the second node 
does not belong to the first network, the first node performs the steps of: 

generating a new random network identification; and 

distributing the new network identification to other nodes in the first network. 

15. An ad-hoc network including a first node which belongs to a first network, 
the first node comprising: 

means for transmitting a neighbor discovery message; 

means for receiving from a second node a neighbor discovery response message, 
wherein the neighbor discovery response message includes an identification of a network 
which the second node belongs to; and 

means for determining which network the second node belongs to using die 
identification. 

16. The first node of claim 15, wherein the means for determining further 
comprises: 

means for comparing the identification received firom the second node with an 
identification stored in the first node; 

means for determining that the second node belongs to a different network if the 
received identification does not match the stored identification. 



wo 01/97447 



• 




CT/SEOl/01301 



-28- 



17. The first node of claim 15, wherein the ad-hoc network is a wireless 
network. 

18. Tlie first node of claim IS, wherein the ad-hoc network operates according 
to Bluetooth protocol. 

19. An ad-hoc network comprising: 

means for selecting by a first node a random network identification; 
means for transferring from the first node to a second node the random network 
identification; 

means for determining by the second node whether to adopt the random network 
identification; and 

means for sending a new network identification message if the second node adopts 
the random network identification. 

20. The ad-hoc network of claim 19, wherein the second node adopts the random 
network identification if a size of a network associated with the random network 
identification is larger than a size of a network associated with the second node. 

21. The ad-hoc network of claim 19, wherein the means for determining 
comprises: 

means for performing an exclusive OR operation using a least significant bit of the 
random network identity and a least significant bit of a network identity associated with the 
second node; and 

means for selecting the higher network identity if a result of the exclusive OR 
operation has a value of one. 

22. The ad-hoc network of claim 19, wherein the means for determining 
conq>rises: 

means for conq)aring a timestamp associated with the random network identity and a 
timestamp associated with a network identity associated with the second node; and 
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means for selecting the network identity with the newer timestamp. 

23. The ad-hoc network of claim 19, wherein the means for determining 
comprises: 

means for determining whether a message which contains the random network 
identity is a periodic change of identification message; 

means for comparing a timestamp associated with the random network identity and a 
timestamp associated with a network identity of the second node; and 

means for determining whether the timestamp associated with the random network 
identity is less than a predetermined amomit of time different than the timestamp associated 
with the network identity of the second node, 

wherein if the timestamp associated with the random network identity is less than a 
predetermined amomit of time different than the timestamp associated with the network 
identity of the second node, the network identity with the older timestamp is selected if the 
message is a periodic change of identification message, 

wherein if the timestamp associated with the random network identity is greater than 
a predetermined amount of time different than the timestamp associated with the network 
identity of the second node, the network identity with the newer timestamp is selected if the 
message is a periodic change of identification message. 

24. The ad-hoc network of claim 19, wherein the means for selecting comprises: 
means for determining whether the first node lias broken a connection with another 

node; 

means for determining whether the first node has a lower address than the another 

node, 

wherein if the first node has broken a coimection with the another node and the first 
node has a lower address, the first node sends a message to the another node, sets a timer, 
determines whether the first node has received a response from the another node and 
generates a new random network identification if the first node has not received a response 
from the another node. 



25. 



In an ad-hoc network a node con:q>rising: 
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means for starting a timer; 

means for randomly selecting a time value; 

means for generating a new random network identification if the timer exceeds the 
randomly selected time value; and 

means for distributing the new network identification to other nodes in the ad-hoc 
network. 

26. The node of claim 25, wherein the new network identification is distributed 
in a message which includes an indication that the new network identification is a 
periodically generated network identification. 

27. In a first ad-hoc network comprising: 

means for determining in a first node whether a connection with a second node has 
been broken; 

means for sending a message from the first node to the second node through the first 
ad-hoc network; 

means for setting a tinaer in the first node; and 

means for determining that the second node does not belong to the first ad-hoc 
network if the first node does not receive a reply from the second node before the 
expiration of the timer. 

28. The ad-hoc network of claim 27, wherein if it is determined that the second 
node does not belong to the first ad-hoc network, the first node generates a new random 
network identification and distributes the new network identification to other nodes in the 
first ad-hoc network. 
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29. In an ad-hoc network including a &st node which belongs to a first network, 
a method for determining whether a second node and a third node belong to the same 
network, the method comprising the steps of: 

distributing from the first node a neighbor discovery message to the second and 
third nodes; 

receiving from the second and third nodes a neighbor discovery response message, 
wherein the neighbor discovery response message includes an identification of a network 
which the second and third nodes belong to; and 

determining whether the second node and third node belong to the same network 
using the identification. 

30. The method of claim 29, wherein the step of determining further comprises 
the steps of: 

comparing the identification received from the second node with the identification 
received from the third node; and 

determining that the second node and the third node belong to different networks if 
the identification received from the second node does not match the identification received 
from the third node. 

31. The method of claim 29, wherein the ad-hoc network is a wireless network. 

32. The method of claim 29, wherem the ad-hoc network operates according to 
Bluetooth protocol. 
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